Ugrás a tartalomhoz

Vállalati architektúra keretrendszer

Ellenőrzött
A Wikipédiából, a szabad enciklopédiából
NIST vállalati architektúra modell 1989-ben indult, az egyik legkorábbi keretrendszer a vállalati architektúrához.[1]

A vállalati architektúra keretrendszer (EA keretrendszer) meghatározza a vállalati architektúra létrehozásának és használatának módját. Egy architekturális keretrendszer elveket és praktikákat tartalmaz a rendszer architektúraleírásának létrehozásához és használatához. Úgy építi fel az architektek gondolkodását, hogy a rendszer leírását területekre, rétegekre vagy nézetekre osztja, és modelleket kínál – általában mátrixokat és diagramokat – az egyes nézetek dokumentálásához. Ez lehetővé teszi rendszerszintű tervezési döntések meghozatalát a rendszer összes elemére nézve, és hosszú távú döntéseket hozhat az új tervezési követelmények, a fenntarthatóság és a támogatás körül.[2]

Áttekintés

[szerkesztés]

A vállalati architektúra a vállalatot nagy és összetett rendszernek vagy úgynevezett rendszerek rendszerének tekinti.[3] A rendszer méretének és összetettségének kezelése érdekében az architekturális keretrendszer olyan eszközöket és megközelítéseket kínál, amelyek segítenek az architekteknek elvonatkoztatni az építők munkájának részletességétől, a vállalati tervezési feladatok középpontba állításához és értékes rendszerleíró dokumentumok készítéséhez.

Az architektúra keretrendszerének elemei strukturált útmutatást nyújtanak, amely három fő területre oszlik:[4]

  • Az architektúra leírása: hogyan lehet a vállalatot rendszerként dokumentálni, több szempontból. Minden nézet az rendszer egy kisebb részét írja le; magában foglalja azokat az egységeket és kapcsolatokat, amelyek az érintettek érdekeit szolgáló különös aggályokkal foglalkoznak; lehet egy lista, egy táblázat, egy diagram vagy ezek összetettebb szintje.
  • Az rendszer tervezésének módszerei: az architektek által követett folyamatok. Általában egy átfogó, fázisokból álló vállalati struktúra folyamata, finomabb szemcsés tevékenységekből álló alacsonyabb szintű folyamatokra bontva. A folyamatot céljai, bemenetei, fázisai (lépései vagy tevékenységei) és kimenetei határozzák meg. Ezt különböző megközelítések, technikák, eszközök, elvek, szabályok és gyakorlatok támogathatják.
  • Architektek szervezete: útmutatás a csapat felépítéséről és a csapat irányításáról, beleértve a szükséges készségeket, tapasztalatokat és képzést.

Történelem

[szerkesztés]
A vállalati architektúra keretrendszer szerkezetének áttekintése (1987–2003). Balra: A Zachman Keretrendszer 1987, NIST Vállalati Architektúra 1989, EAP 1992, TISAF 1997, FEAF 1999 és TEAF 2000. Jobbra: POSIX által támogatott TAFIM. JTA, JTAA, TOGAF 1995, DoD TRM és C4ISR 1996, és DoDAF 2003.

Az Open Group Architecture Framework (TOGAF) és más EA keretrendszerek által jelenleg támogatott fokozatos tervezési módszertan legkorábbi kezdeményezései Marshall K. Evans és Lou R. Hague "Információs rendszerek főterve" című cikkére vezethetők vissza.[5] 1962-ben jelent meg a Harvard Business Review-ban.[6]

Az 1970-es évek óta az IS / IT területén dolgozók az üzleti emberek bevonásának módját keresték – az üzleti szerepek és folyamatok lehetővé tétele érdekében – és az üzleti információs rendszerekbe és technológiákba történő befektetések befolyásolására, tekintettel a vállalkozás széles és hosszú távú előnyeire. Az EA keretrendszerekben most alkalmazott célok, elvek, koncepciók és módszerek közül sok az 1980-as években jött létre, és megtalálható ebben és az ezt követő évtizedben közzétett IS és IT architektúra keretrendszerekben.[7]

1980-ig az IBM üzleti rendszerek tervezését (BSP) népszerűsítették a szervezet információs rendszerének elemzésére és tervezésére szolgáló módszerként, a következő célokkal:

  1. megérteni a kérdéseket és lehetőségeket a jelenlegi alkalmazásokkal és a műszaki rendszerrel kapcsolatban;
  2. kidolgozni egy jövőbeli állapotot és migrációs utat a vállalkozást támogató technológia számára;
  3. iránymutatást és döntéshozatali keretet biztosít az üzleti vezetők számára az informatikai beruházásokra vonatkozóan;
  4. ellátja az információs rendszert (IS) a fejlesztés tervével.

1982-ben, amikor az IBM-nél és a BSP-nél dolgozott, John Zachman felvázolta a vállalati szintű "információs rendszerek architektúrájának" keretrendszerét. Majd a későbbiekben Zachman a vállalkozás szót az üzleti szó szinonimájaként használta. "Bár számos népszerű információs rendszertervezési módszertan, tervezési megközelítés, valamint különféle eszközök és technikák nem zárják ki vagy nem ellentétesek a vállalati szintű elemzéssel, közülük kevesen foglalkoznak kifejezetten a vállalati architektúrákkal vagy próbálják azokat meghatározni."[8] Ebben a cikkben azonban az "Vállalati Architektúra" kifejezést csak egyszer említették meg különösebb meghatározás nélkül, és Zachman minden későbbi műve az "Információs Rendszerek Architektúrája" kifejezést használta.[9] [10]

1986-ban a PRISM architektúra keretrendszert egy vállalatcsoport, köztük az IBM által támogatott kutatási projekt eredményeként fejlesztették ki, amely látszólag az első publikált EA keretrendszer volt.[11]

1987-ben John Zachman, aki az IBM marketing szakembere volt, kiadta az Egy keretrendszer az Információs Rendszerek Architektúrájának című cikket.[9] A cikk egy osztályozási sémát biztosított a munkaanyag számára, amely leírja (az absztrakció több szintjén), hogy az információs rendszerek alapjait. Mivel az IBM már alkalmazta a BSP-t, Zachmannak nem volt szüksége a tervezési folyamatra. A lap nem említette a vállalati architektúrát.

1989-ben a Nemzeti Szabványügyi és Technológiai Intézet (NIST) közzétette a NIST Vállalati Architektúra Modell-t.[12] Ez egy ötrétegű referenciamodell volt, amely szemlélteti az üzleti, információs rendszer és technológiai területek kölcsönös kapcsolatát. Az USA szövetségi kormányán belül népszerűsítették. Nem ez volt az EA keretrendszere, ahogy most látjuk, de segített megalapozni az EA architektúra-tartományokra vagy rétegekre bontásának fogalmát. A NIST Vállalati Architektúra Modell látszólag az első olyan kiadvány volt, amely következetesen használta az „Vállalati Architektúra” kifejezést.[11]

1990-ben az "Vállalati Architektúra" kifejezést hivatalosan először olyan architektúraként definiálták, amely "meghatározza és összekapcsolja az adatokat, a hardvert, a szoftvert és a kommunikációs erőforrásokat, valamint az rendszer által megkövetelt általános fizikai struktúra fenntartásához szükséges támogató szervezetet".[11] [13]

1992-ben Zachman és Sowa tanulmánya[10] megkezdődött, így "John Zachman bevezette az információs rendszerek architektúrájának (ISA) keretrendszerét, amelyet a rendszerelemzők és az adatbázis-tervezők széles körben átvettek". A vállalati architektúra kifejezés nem jelent meg. A cikk az ISA keretrendszer használatáról szólt, hogy: "... az általános információs rendszer hogyan kapcsolódik a vállalkozáshoz és annak környezetéhez." A vállalkozás szót az üzleti szó szinonimájaként használták.

1993-ban Stephen Spewak Vállalkozás-Architektúra Tervezés (EAP) című könyve meghatározta az üzleti támogatásra szolgáló információk felhasználására szolgáló architektúrákat és ezek megvalósításának tervét. Az üzleti küldetés az elsődleges mozgatórugó. Ezután a küldetés teljesítéséhez szükséges adatok. Az alkalmazások pedig az adatok tárolására és biztosítására épültek. Végül az alkalmazások megvalósításához szükséges technológia. A Vállalati Architektúra Tervezés egy adatközpontú megközelítés az rendszer tervezéshez. Cél az adatok minőségének javítása, az adatokhoz való hozzáférés, a változó követelményekhez való alkalmazkodóképesség, az adatok átjárhatósága és megosztása, valamint a költségek korlátozása. Az EAP az IBM Üzleti Rendszerek Tervezésében (BSP) gyökerezik.[11]

1994-ben az Open Group kiválasztotta a TAFIM -ot az amerikai DoD-ből a TOGAF fejlesztésének alapjául, ahol az architektúra az IT-architektúrát jelentette. A TOGAF stratégiai és vállalati szintű, de technológia-orientált szemléletet kezdett kialakítani. A rendezetlen informatikai ingatlanok ésszerűsítésének vágyából fakadt. Egészen a 7. verzióig a TOGAF továbbra is a műszaki referenciamodell (vagy az alap architektúra) meghatározására és használatára összpontosított, hogy meghatározza az egész vállalat által az üzleti alkalmazások támogatásához használt technológiáktól megkövetelt platformszolgáltatásokat.[7]

1996-ban az Egyesült Államok IT-menedzsmentre vonatkozó törvénye, közismertebb nevén Clinger-Cohen Act többször kimondta, hogy az Egyesült Államok szövetségi kormányzati ügynökségének az informatikába történő befektetését azonosítható üzleti előnyökhöz kell feltérképezni. Ezen túlmenően az ügynökség CIO-ját felelőssé tette: "... a végrehajtó ügynökség megbízható és integrált informatikai architektúrájának kidolgozásáért, fenntartásáért és megvalósításának elősegítéséért".

1997-re Zachman átnevezte és újraszabályozta ISA keretrendszerét EA keretrendszerré; ez továbbra is a leíró munkaanyagok osztályozási rendszere maradt, nem pedig a rendszerek tervezésének vagy rendszerváltozásoknak a folyamata.

1998-ban a Szövetségi CIO Tanács megkezdte a Szövetségi Vállalkozási Architekturális Keretrendszer (FEAF) fejlesztését a Clinger-Cohen-ben megfogalmazott prioritásoknak megfelelően, és 1999-ben kiadta azt. A FEAF a TOGAF ADM-hez hasonló folyamat volt, amelyben „Az architektúra csapat szekvenciatervet készít a rendszerek, alkalmazások és a kapcsolódó üzleti gyakorlatok átmenetére, amely részletes réselemzésre támaszkodik [az alap és a célarchitektúra között].”

2001-ben az Egyesült Államok CIO-főtanácsa közzétette a Szövetségi Vállalkozási Architektúra gyakorlati útmutatóját, amely így kezdődik: „A vállalati architektúra (EA) meghatározza az Ügynökség egészére kiterjedő ütemtervet az Ügynökség küldetésének elérésére azáltal, hogy az alapvető üzleti folyamatait optimálisan teljesíti, hatékony információ technológiai (IT) környezett segítségével. " Ekkor a TOGAF, a FEAF, az EAP és a BSP folyamatai egyértelműen összefüggésben voltak.

2002/3-ban Enterprise TO kiadásában a TOGAF 8 a technológiai architektúra rétegről a magasabb üzleti, adat és alkalmazás rétegekre helyezte a hangsúlyt. Bevezette a strukturált elemzést az informatikai tervezés után, amely például a szervezeti egységek, az üzleti funkciók és az adatelemek üzleti funkciókhoz való hozzárendelését tartalmazza. Ma az üzleti funkciókat gyakran üzleti képességeknek nevezik. Sok vállalati architekt pedig az üzleti funkciók/képességek hierarchiáját/térképét tekinti a vállalati architektúra alapvető műtárgyának. Az adatok entitásokat, felhasználási eseteket, alkalmazásokat és technológiákat kapcsolják a funkciókhoz / képességekhez.

2006-ban az Enterprise Architecture As Strategy[14] beszámolt az MIT Információs Rendszer Kutató Központjának munkájának eredményeiről. Ez a könyv hangsúlyozza annak szükségességét, hogy a vállalati architekteknek az alapvető üzleti folyamatokra kell összpontosítaniuk ("A vállalatok kiemelkedőek, mert [eldöntötték, hogy mely folyamatokat kell jól végrehajtaniuk, és bevezetik az informatikai rendszereket e folyamatok digitalizálásához"), és be kell vonniuk az üzleti vezetőket. azokkal az előnyökkel, amelyeket a stratégiai, szervezetközi folyamatintegráció és/vagy szabványosítás nyújthat.

A British Computer Society (BCS) által a vállalati és megoldási architektúra szakmai tanúsítványainak fejlesztését célzó 2008-as kutatási projekt azt mutatta, hogy a vállalati architektúra mindig elválaszthatatlan volt az információs rendszer architektúrájától, ami természetes, hiszen az üzletembereknek információra van szükségük a döntések meghozatalához és az üzleti folyamatok végrehajtásához.[7]

2011-ben a TOGAF 9.1.-es a specifikációja szerint: "Az üzleti tervezés stratégiai szinten biztosítja a kezdeti irányt a vállalati architektúra számára."[15] Általában a szervezet üzleti elveit, üzleti céljait és stratégiai mozgatórugóit máshol határozzák meg.[7] Más szavakkal, a Vállalati Architektúra nem üzleti stratégia, tervezés vagy menedzsment módszertan. A Vállalati Architektúra arra törekszik, hogy az üzleti információs rendszerek technológiáját összehangolja az adott üzleti stratégiával, célokkal és mozgatórugókkal. A TOGAF 9.1 specifikációja egyértelművé tette, hogy "A teljes vállalati architektúra leírásnak tartalmaznia kell mind a négy architektúra tartományt (üzleti, adat, alkalmazás, technológia), de az erőforrások realitása és az időbeli korlátok gyakran azt jelentik, hogy nincs elegendő idő, finanszírozás vagy erőforrás egy felülről lefelé építkező, mindenre kiterjedő architektúra-leírás felépítésére, amely magában foglalja mind a négy architektúra-tartományt, még akkor is, ha a vállalati hatókör [...] kisebb, mint a teljes vállalkozás teljes terjedelme."[16]

2013-ban a TOGAF[17] volt a legnépszerűbb architekturális keretrendszer (a közzétett tanúsítási számok alapján ítélve), amely egyesek szerint, meghatározta az EA-t.[7] Egyesek azonban továbbra is a Vállalati Architektúra kifejezést használják az üzleti architektúra szinonimájaként, ahelyett, hogy mind a négy architektúra területet lefednék – üzleti, adat, alkalmazások és technológia.

EA keretrendszer témák

[szerkesztés]

Architektúra terület

[szerkesztés]
A vállalati architektúra szintjei[18]

Stephen Spewak 1993-as Enterprise Architecture Planning (EAP) című munkája óta, de talán már azelőtt is, bevett szokás volt a vállalati architektúrát négy architektúra-területre osztani.

Megjegyzendő, hogy az alkalmazásarchitektúra a vállalat alkalmazásportfóliójában lévő alkalmazások kiválasztására és az alkalmazások közötti kapcsolatokra vonatkozik, nem pedig egyetlen alkalmazás belső architektúrájára (amelyet gyakran neveznek alkalmazásarchitektúrának).

Számos EA keretrendszer egyesíti az adat- és alkalmazástartományokat egyetlen (digitalizált) információs rendszerrétegben, az üzleti (általában emberi tevékenységi rendszer) alatt és a technológiai (a platform informatikai infrastruktúrája ) felett helyezkedik el.

A vállalati architektúra rétegei

[szerkesztés]
Példa a szövetségi vállalati architektúrára, amely öt architektúrális réteget határozott meg.[19]

Hosszú évek óta gyakori, hogy az architekturális tartományokat rétegeknek tekintik, azzal a gondolattal, hogy minden réteg olyan részeket tartalmaz, amelyek folyamatokat hajtanak végre és szolgáltatásokat kínálnak a feljebb lévő réteg számára. Ez a nézet az architekturális területeken nyilvánvalóvá vált a TOGAF v1-ben (1996), amely a „Technikai Referencia Modellben” meghatározott platformszolgáltatások mögé helyezte a technológiai komponens réteget – ami nagyon is megfelel a TAFIM és a POSIX filozófiájának.

Az architektúra tartományok mint rétegek nézete így mutatható be:

  • Környezet (a vállalkozás által felügyelt, támogatott vagy irányított külső szervezetek és tevékenységek).
  • Üzleti réteg (üzleti funkciók, amelyek szolgáltatásokat nyújtanak egymásnak és külső szervezeteknek).
  • Adatréteg (üzleti információk és egyéb értékes tárolt adatok)
  • Információs rendszer réteg (üzleti alkalmazások, amelyek információs szolgáltatásokat nyújtanak egymásnak és üzleti funkcióknak)
  • Technológiai réteg (Generikus hardver, hálózati és platform alkalmazások, amelyek platformszolgáltatásokat kínálnak egymásnak és üzleti alkalmazásoknak).

Minden réteg delegálja a munkát az alatta lévő rétegnek. Az egyes rétegekben a komponensek, a folyamatok és a szolgáltatások durva szemcsés szinten definiálhatók, és finomabb szemcsés komponensekre, folyamatokra és szolgáltatásokra bonthatók. A grafikon ennek a témának egy variációját mutatja be.

A vállalati architektúra keretrendszer elemei

[szerkesztés]

A fent említett három fő keretrendszer komponens mellett.

  1. Leírás tanácsok: valamilyen Architektúra Artifact Térkép vagy Nézőpont Könyvtár
  2. Folyamat tanácsadás: valamilyen architektúra fejlesztési módszer, támogató útmutatással.
  3. Szervezeti tanácsok: beleértve az EA irányítási modelljét

Az ideális EA keretrendszernek tartalmaznia kell:

  1. Üzleti érték mérési mutatók
  2. EA kezdeményezési modell
  3. EA lejárati modell
  4. Vállalati kommunikációs modell

A legtöbb modern EA keretrendszer (pl TOGAF, ASSIMPLER, EAF) tartalmazza a fentiek nagy részét. Zachman mindig az architektúra leírásokra összpontosított.

Vállalati architektúra tartományok és altartományok

[szerkesztés]
Vállalati architektúra referencia architektúra altartományokkal

Az alkalmazási és technológiai tartományokat (nem tévesztendő össze az üzleti területekkel) a tartományi képességek és a tartományi szolgáltatások jellemzik. A képességeket a szolgáltatások támogatják. Az alkalmazási szolgáltatásokra a szolgáltatás-orientált architektúrában (SOA) is hivatkozunk. A műszaki szolgáltatásokat általában szoftvertermékek támogatják.

Az adatnézet az adatosztályokkal kezdődik, amelyeket adattárgyakra lehet bontani, amelyek tovább bonthatók adategységekre. A leggyakrabban használt alapadat-modell típusát merda-nak hívják (mester entitás kapcsolati diagramok értékelése, lásd entitás-kapcsolat modell). Az osztály, a tárgy és az entitás hierarchikus képet alkot az adatokról. A vállalkozásoknak több millió példánya lehet adatintézményeknek.

A hagyományos vállalati architektúra-referenciamodell egyértelműen megkülönbözteti az architektúra-területeket (üzleti, információ / adatok, alkalmazás / integráció és műszaki / infrastruktúra). Ezek a tartományok tovább bonthatók altartomány tudományágakra. A jobb oldali képen egy példa látható az EA-tartományra és az altartományokra.

Számos vállalati architektúracsapat olyan személyekből áll, akik készségekkel rendelkeznek, összhangban vannak az Vállalati Architektúra Tartományokkal és altartomány tudományágakkal. Íme néhány példa: vállalati üzleti architekt, vállalati dokumentációs architekt, vállalati alkalmazás architekt, vállalati infrastruktúra architekt, vállalati információs architekt stb.

Az alkalmazás és az információs architektúra tartományában található referencia architektúra minták listájára példa található az Architectural pattern (informatika) oldalon.

Nézetmodell

[szerkesztés]
Illusztráció a 4 + 1 nézetmodell architektúrára

A nézetmodell olyan keretrendszer, amely meghatározza a rendszerelemzésben, a rendszertervezésben vagy a vállalati architektúra felépítésében használt nézetek vagy megközelítések összességét.

Az 1990-es évek eleje óta számos erőfeszítést tettek a rendszerarchitektúrák leírásának és elemzésének mérvadó megközelítéseinek meghatározására. A közelmúltban a Vállalati Architektúra keretrendszerekben számos nézetkészlet van definiálva, de ezeket a halmazokat nem mindig nevezzük nézetmodelleknek.

Szabványosítás

[szerkesztés]

A szoftverarchitektúra és a rendszerarchitektúra terén talán a legismertebb szabvány az IEEE 1471 néven indult, amely egy 2000-ben jóváhagyott szoftverintenzív rendszer architektúrájának leírására szolgáló IEEE szabvány/

A szabvány legújabb változata ISO/IEC/IEEE 42010:2011 néven jelent meg. A szabvány az architektúra keretrendszerét egy adott alkalmazási területen és / vagy az érdekelt felek közösségében létrehozott architektúrák leírásának konvencióiként, alapelveiként és gyakorlataként határozza meg, és javasolja, hogy az architektúra keretrendszerét az alábbiak határozzák meg:

  1. a terület érintett szereplői,
  2. az adott területen felmerülő aggályok típusai,
  3. architekturális szempontok, amelyek megfogalmazzák ezeket az aggályokat, és
  4. az előbb említett szempontokat integráló összehangolt szabályok.

A szabványnak megfelelő architekturális keretrendszerek további módszereket, eszközöket, definíciókat és gyakorlatokat tartalmazhatnak a megadottakon túl.

A vállalati architektúra keretrendszer típusai

[szerkesztés]
Csak néhány a ma használt vállalati architektúra keretrendszerek közül, 2011[20]

Manapság már számtalan EA keretrendszer létezik, sokkal több, mint a következő felsorolásban.

Konzorciumok által kidolgozott keretek

[szerkesztés]
  • ARCON – Együttműködési hálózatok referenciaarchitektúrája – nem egyetlen vállalkozásra, hanem inkább a vállalkozások hálózataira összpontosít[21] [22]
  • A Cloud Security Alliance (Trusted Cloud Initiative) TCI referencia architektúra.[23]
  • Általános vállalati referenciaarchitektúra és módszertan (GERAM)
  • RM-ODP – a nyílt elosztott feldolgozás referenciamodellje (ITU-T Rec. X.901-X.904 Az ISO / IEC 10746) meghatározza a nyílt elosztott rendszerek specifikációinak strukturálásához a vállalati architektúra keretrendszerét.
  • IDEAS Group – négy ország közös ontológia kidolgozására irányuló erőfeszítése az architekturális átjárhatóság érdekében
  • ISO 19439 keretrendszer a vállalati modellezéshez
  • TOGAF – The Open Group Architecture Framework – széles körben használt keretrendszer, amely magában foglal egy architekturális fejlesztési módszert és szabványokat az architektúra különféle típusainak leírására.

Hadipari keretrendszerek

[szerkesztés]
  • AGATE – a franciaországi DGA-architektúra keretrendszer
  • DNDAF[24] – a DND / CF Architektúra Keretrendszer (CAN)
  • DoDAF – az Egyesült Államok Védelmi Minisztériumának Architektúra Keretrendszere
  • MODAF -az Egyesült Királyság Védelmi Minisztériumának Architektúra Keretrendszere
  • NAF – a NATO Architektúra Keretrendszere

Kormányzati keretrendszerek

[szerkesztés]

Nyílt forráskódú keretrendszerek

[szerkesztés]

Nyílt forráskódként kiadott vállalati architektúra keretrendszerek:

  • A Lean Architecture Framework (LAF)[27] olyan jó gyakorlatok gyűjteménye, amelyeknek köszönhetően az informatikai környezet következetesen és gyorsan reagál a változó üzleti helyzetre, fenntartva annak állandó formáját.
  • A MEGAF[28] egy infrastruktúra az architektúra keretrendszerek megvalósításához, amelyek megfelelnek az architektúra keretrendszer ISO / IEC / IEEE 42010 szabványban megadott meghatározásnak.
  • A Praxeme, egy nyílt vállalati módszertan, az Enterprise System Topology (EST) nevű vállalati architektúra keretrendszert tartalmazza.
  • TRAKa MODAF 1.2-n alapuló és a GPL / GFDL alatt kiadott általános rendszerorientált keretrendszer.
  • A Sherwood Applied Business Security Architecture (SABSA)[29] egy nyílt forráskódú keretrendszer és módszertan az Enterprise Security Architecture és a Service Management számára, amely kockázatalapú és arra összpontosít, hogy beépítse a biztonságot az üzleti és informatikai menedzsmentbe.

Saját tulajdonú keretek

[szerkesztés]
  • ASSIMPLER Framework – egy architektúra keretrendszer, amely Mandar Vanarse 2002-es Wipro munkáján alapul.
  • Avancier Methods (AM)[30] Folyamatok és dokumentációs tanácsadás vállalati és megoldás-architekteknek, képzésekkel és tanúsítással támogatva.
  • BRM (Build-Run-Manage) Framework – architektúra keretrendszer, amelyet Sanjeev "Sunny" Mishra hozott létre az IBM korai szakaszában, 2000-ben.
  • Capgemini Integrated Architecture Framework (IAF) – a Capgemini cégtől 1993-ban
  • Dragon1 – Egy nyílt vizuális vállalati architektúra-módszer, amelyet a The Open Group nemrégiben Vállalati Keretrendszerként ismert el.
  • A DYA keretrendszert a Sogeti 2004 óta fejleszti.
  • Dynamic Enterprise – Web 2.0 technológián alapuló vállalati architektúra-koncepció
  • Extended Enterprise Architecture Framework – az Enterprise Architecture Developments Institute által, 2003-ban
  • EACOE keretrendszer [1] – egy Enterprise Architecture keretrendszer, John Zachman munkájának feldolgozásaként
  • IBM Information FrameWork (IFW) – amelyet Roger Evernden tervezett 1996-ban
  • Infomet – Pieter Viljoen tervezte 1990-ben
  • Labnaf[31] – Egységes keretrendszer a vállalati átalakítások ösztönzéséhez
  • Pragmatic Enterprise Architecture Framework (PEAF)[32] – a Pragmatic Family of Frameworks része, amelyet Kevin Lee Smith, Pragmatic EA, 2008-tól fejlesztett ki.
  • The Purdue Enterprise Reference Architecture, amelyet Theodore J. Williams fejlesztett ki a Purdue Egyetemen az 1990-es évek elején.
  • SAP Enterprise Architecture Framework
  • Szolgáltatásorientált modellezési keretrendszer (SOMF) , Michael Bell munkája alapján
  • Megoldás-architektúra mechanizmus (SAM)[33] – Koherens architektúra-keret, amely integrált modulokból áll.[34]
  • Zachman Framework – Architektúra keretrendszer, amely John Zachman munkáján alapult az IBM-nél a nyolcvanas években

Hivatkozások

[szerkesztés]
  1. The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1 Archiválva 2012. február 13-i dátummal a Wayback Machine-ben.. September 1999.
  2. Tech Target. SearchCIO
  3. The Open Group (2008) TOGAF Version 9. Van Haren Publishing, 1 nov. 2008.p. 73
  4. Stephen Marley (2003). Architectural Framework. NASA /SCI. At Webarchive.org, retrieved 3-04-2015.
  5. Evans, M. K. and Hague, L. R. (1962) Master Plan for Information Systems, Harvard Business Review, Vol. 40, No. 1, pp. 92-103.
  6. Kotusev, Svyatoslav (2018) The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment. Melbourne, Australia: SK Publishing.
  7. a b c d e Graham Berrisford (2008-13) "A brief history of EA: what is in it and what is not Archiválva 2013. szeptember 18-i dátummal a Wayback Machine-ben." on grahamberrisford.com, last update 16/07/2013. Accessed 16/07?2003
  8. John Zachman (1982) Business Systems Planning and Business Information Control Study: A comparison in IBM Systems Journal 21(1). p32.
  9. a b John A. Zachman (1987). A Framework for Information Systems Architecture. In: IBM Systems Journal, vol 26, no 3. IBM Publication G321-5298.
  10. a b Zachman and Sowa (1992) Extending and formalising the framework of information systems architecture IBM Systems Journal, Vol 31, No 3
  11. a b c d Svyatoslav Kotusev (2016). The History of Enterprise Architecture: An Evidence-Based Review. In: Journal of Enterprise Architecture, vol. 12, no. 1, pp. 29-37.
  12. W.B. Rigdon (1989). Architectures and Standards. In Information Management Directions: The Integration Challenge (NIST Special Publication 500-167), E.N. Fong, A.H. Goldfine (Eds.), Gaithersburg, MD: National Institute of Standards and Technology (NIST), pp.135-150.
  13. Richardson (1990). „A Principles-Based Enterprise Architecture: Lessons from Texaco and Star Enterprise”. MIS Quarterly 14 (4), 385–403. o. DOI:10.2307/249787. 
  14. Jeanne W. Ross, Peter Weill, and David C. Robertson ( (2006) Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press
  15. The Open Group (2011) TOGAF® 9.1 > Part II: Architecture Development Method (ADM) > Preliminary Phase. Accessed July 16, 2013
  16. The Open Group (2011) TOGAF® 9.1 > Part II: Architecture Development Method (ADM) > Introduction to the ADM. Accessed July 16, 2013
  17. TOGAF 9.1 White Paper An Introduction to TOGAF Version 9.1 http://www.opengroup.org/togaf/
  18. Niles E Hewlett (2006), The USDA Enterprise Architecture Program Archiválva 2007. május 8-i dátummal a Wayback Machine-ben.. PMP CEA, Enterprise Architecture Team, USDA-OCIO. January 25, 2006.
  19. FEA Consolidated Reference Model Document Archiválva 2010. július 5-i dátummal a Wayback Machine-ben.. whitehouse.gov May 2005.
  20. Dennis E. Wisnosky (2011) Engineering Enterprise Architecture: Call to Action. in: Common Defense Quarterly. January 2011, p. 9
  21. L.M. Camarinha-Matos, H. Afsarmanesh, Collaborative Networks: Reference Modeling, Springer, 2008.
  22. Camarinha-Matos (2008). „On reference models for collaborative networked organizations”. International Journal Production Research 46 (9), 2453–2469. o. DOI:10.1080/00207540701737666. 
  23. The CSA TCI reference architectue. Cloud Security Alliance. [2016. június 11-i dátummal az eredetiből archiválva]. (Hozzáférés: 2020. július 7.) „""”
  24. DNDAF Archiválva 2011. április 24-i dátummal a Wayback Machine-ben.
  25. Gianni, Daniele. Introducing the European Space Agency Architectural Framework for Space-Based Systems of Systems Engineering, Complex Systems Design & Management. Proceedings of the Second International Conference on Complex Systems Design & Management CSDM 2011. Springer, 335–346. o.. DOI: 10.1007/978-3-642-25203-7_24 (2012). ISBN 978-3-642-25202-0 
  26. US Department of the Treasury Chief Information Officer Council (2000). Treasury Enterprise Architecture Framework Archiválva 2009. március 18-i dátummal a Wayback Machine-ben.. Version 1, July 2000.
  27. https://lafinstitute.org/
  28. MEGAF
  29. SABSA
  30. Avancier Methods (AM)
  31. Labnaf
  32. Pragmatic EA
  33. Solution Architecting Mechanism (SAM)
  34. Tony Shan and Winnie Hua (2006). Solution Architecting Mechanism. Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference (EDOC 2006), October 2006, p23-32.

 

Fordítás

[szerkesztés]

Ez a szócikk részben vagy egészben az Enterprise architecture framework című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További információk

[szerkesztés]